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(54) Medical diagnostic 



service connectivity method and apparatus 



(57) A technique is provided for verifying network 
connectivity between a medical diagnostic system (12, 
1 4, 1 6, 1 8, 22, 24 26) and a remote service facility (20). 
The remote service facility (20) is contactable at will by 
the subscribing system to request service, information, 
technical assistance, and so forth, while the service 
facility may also contact the subscribing system for 
acquisition of data, transmission of service messages, 
protocols, and so forth. In the connectivity verification 
sequence, a subscribing system (12, 14, 16, 18, 22, 24, 
26) is selected by the service facility and a network con- 
nection (44) is established. A message is transmitted to 



the system provoking software at the system to re- 
establish the network connection from the system side. 
Two-way connectivity is thereby verified. Mobile sys- 
tems (16, 18) may be configured to contact the service 
facility at their own initiation, and exchange data for per- 
mitting the service facility to re-contact the mobile sys- 
tem. Failure modes may be identified at various 
locations in the connectivity network by identification of 
steps in the connectivity verification process where the 
process failed. Alerts or other action items may be gen- 
erated as a result of detected connectivity problems. 



CM 
< 




Q_ 

LU 



1 EP 1 081 627 A2 2 



Description 

[0001] The present invention relates generally to 
systems and techniques for providing remote service to 
medical diagnostic equipment and facilities. More par- 5 
ticularly, the invention relates to a technique for verifying 
continued connectivity between a remote service facility 
and a subscribing medical diagnostic facility or system. 
[0002] In recent years, considerable advances have 
been made in medical diagnostic equipment and sys- w 
terns, particularly imaging systems. Such imaging sys- 
tems encompass a range of modalities, each 
characterized by the physics involved in acquiring and 
processing image data. At present, medical diagnostic 
imaging modalities include magnetic resonance imag- 15 
ing (MRI) systems, x-ray systems, both digital and con- 
ventional film-based, computed tomography (CT) 
systems, ultrasound systems, positron emission tomog- 
raphy (PET) systems, and so forth. Medical facilities, 
hospitals and clinics make use of a wide range of such 20 
equipment, including more than one of the modalities, 
and in certain cases, more than one system within each 
modality. In larger facilities, these systems may be net- 
worked in a radiology department to permit common 
management or control. Such systems are increasingly 25 
associated with picture archiving and communications 
systems (PACS) for storing digitized image data for sub- 
sequent retrieval and reconstruction of useful images. 
Moreover, teleradiology applications are on the rise, in 
which such digitized data may be transmitted to remote 30 
locations, such as for review and diagnosis by special- 
ized physicians and radiologists. 
[0003] Regardless of the particular modality, medi- 
cal diagnostic systems are often a key element in the 
diagnosis and treatment of disease and ailments. While 35 
certain facilities may offer their services during specific 
periods during the day, others require continued access 
to the diagnostic equipment in very demanding sched- 
ules. In both cases, the facility has a critical interest in 
maintaining the diagnostic equipment in good opera- 40 
tional condition. However, due to the complexity of the 
systems, personnel required to review and evaluate 
potential problems as they arise are not often present at 
the location where the systems are found. Conse- 
quently, remote servicing of medical diagnostic equip- 45 
ment has become an important tool in maintaining the 
systems. 

[0004] Traditionally, remote servicing of medical 
diagnostic equipment was performed via telephone. 
Operations personnel would call a remote service facil- 50 
ity to report malfunctions and to ask questions regard- 
ing the proper operation and settings for the equipment. 
Where such queries could not be sufficiently handled by 
telephone, a service engineer was dispatched to trou- 
bleshoot the system or to provide the needed assist- 55 

[0005] Improvements in computer networks have 
greatly facilitated the task of offering assistance to med- 



ical diagnostic equipment and facilities. In particular, 
rather than simply calling a remote service facility and 
either talking directly to a technician or engineer, or 
awaiting a return call from a service center, network 
technologies have facilitated proactive techniques 
wherein the service center may contact the medical 
diagnostic equipment or facility to check the status of 
subscribing equipment. 

[0006] Further advancements have been proposed 
to providing remote service to medical diagnostic sys- 
tems in an effort to provide the level of service on a con- 
tinual and interactive basis needed by many facilities. In 
one system, a remote service facility can interactively 
receive messages via a network, and can respond auto- 
matically to the messages either in a single connection 
session or in a subsequent session. Data required to 
analyze the state of operation of the medical diagnostic 
equipment can be transferred during the initial or subse- 
quent sessions. The technique greatly facilitates identi- 
fication of system problems, allows questions to be 
posed to the subscribing service provider, facilitates 
transfer of updates and imaging protocols, and permits 
standard and customized reports to be transmitted to 
subscribing systems. The interactive aspect of the tech- 
nique allows the medical diagnostic facility to remain 
current on services provided by the remote service facil- 
ity and to communicate at will with the service facility. 
[0007] While these advancements in the provision 
of remote services to medical diagnostic equipment 
have greatly enhanced the level of service and informa- 
tion exchange, they may be subject to difficulties, partic- 
ularly those arising from unanticipated connectivity 
problems. In particular, exchange of service information 
and requests on an interactive basis assumes that the 
remote service facility can contact the subscribing sys- 
tems at will, and, conversely, that the subscribing sys- 
tems can freely contact the remote service provider. 
Where systems operate well and no service is needed, 
extended periods may transpire without a contact of the 
service facility. If the required connection between the 
diagnostic equipment and the service facility is inopera- 
tive, however, service requests may not be reliably sub- 
mitted to the service facility, and information from the 
service facility to the diagnostic system may not arrive 
properly or in a timely manner. Operator intervention 
may sometimes detect such problems, but typically only 
after a needed response has not been received for 
some time. Such delays would advantageously be 
avoided to insure that service problems and questions 
can be addressed in a timely manner. 
[0008] There is a need, therefore, for a technique 
adapted to monitor proper connectivity of medical diag- 
nostic equipment and facilities with a remote service 
provider. There is, at present, a particular need for a 
system which can verify two-way connectivity in which a 
service facility can freely contact a subscribing diagnos- 
tic system, and a diagnostic system can contact the 
service facility. 
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[0009] The present invention provides a connectiv- 
ity verification technique designed to respond to these 
needs. The technique may be employed with any of a 
variety of diagnostic equipment, including specific sys- 
tems of various modalities and centralized management 
systems, such as those typically found in large radiology 
departments. Where the diagnostic system is connecta- 
ble to a remote service facility, the technique permits the 
service facility to verify that the connection can be 
established, both originating from the service facility 
and from the diagnostic equipment. Such connections 
may be made with specific systems, with management 
systems networked to the diagnostic systems at a spe- 
cific facility, or both. Moreover, the connectivity verifica- 
tion may be timed or scheduled for automatic 
implementation, or could be performed manually. The 
system may be designed to provide at least some 
degree of diagnostic capabilities in which the type or 
location of connectivity problem is detected and 
recorded. Results of connectivity verifications can be 
stored and used to evaluate the operability of the overall 
system, and to improve the system where needed. 
Upon failure of the connectivity test, or when inconsist- 
ent or unreliable connectivity is identified, the system 
may permit notification via an operator, or via auto- 
mated schemes, including electronic messaging, pag- 
ing, and so forth. The system may be adapted both for 
stationary diagnostic systems, as well as for mobile sys- 
tems. In the case of mobile systems, the system may be 
adapted to await contact of the service facility by the 
mobile equipment. 

[0010] The technique is particularly well suited to 
interactive service systems in which a diagnostic facility 
may contact a remote service provider and a remote 
service provider may contact the diagnostic facility. In 
addition, the system is especially adaptable to service 
arrangements in which subscriptions or licenses are 
established between the service facility and the diag- 
nostic equipment. Based upon such subscriptions, the 
service facility insures the connectivity between the 
diagnostic equipment and the service provider to allow 
the service provider to be contacted by the equipment 
managers, or automatically by the system without oper- 
ator intervention. 

[0011] An embodiment of the invention will now be 
described, by way of example, with reference to the 
accompanying drawings, in which: 

Fig. 1 is a diagrammatical representation of a series 
of medical diagnostic systems and facilities linked 
to a remote service facility over a network; 

Fig. 2 is a diagrammatical representation of certain 
of the functional components of one of the diagnos- 
tic systems shown in Fig. 1 and of the remote serv- 
ice facility; 

Fig. 3 is a data flow diagram illustrating certain of 



the signals and data exchanged between the serv- 
ice facility and the diagnostic equipment in a con- 
nectivity verification scheme in accordance with 
certain aspects of the invention; 

Fig. 4 is a flow chart illustrating steps in exemplary 
control logic for performing a connectivity verifica- 
tion scheme; and, 

w Fig. 5 is a flow chart illustrating exemplary control 
logic for connectivity verification with a mobile diag- 
nostic system. 

[0012] Referring now to Fig. 1, a medical diagnostic 

w and service arrangement, designated generally by the 
reference numeral 10, is illustrated as including a plural- 
ity of medical diagnostic systems or stations, and a 
remote service facility connected by a network link. In 
the diagrammatic representation of Fig. 1 , arrangement 

20 10 includes diagnostic equipment provided in a central 
facility or institution 12, along with independent diagnos- 
tic systems 14, and mobile diagnostic systems 16 and 
18. The various systems, including those within facility 
12, are configured to be selectively linked to a remote 

25 service facility 20. Service facility 20 is contacted by the 
systems, and may contact the systems, as required, to 
provide service to the systems and facilities, to address 
concerns or service requests transmitted from the vari- 
ous systems and equipment, access data from the sys- 

30 terns, transmit data to the systems, and so forth. 

[0013] In general, arrangement 10 may include any 
of a variety of medical diagnostic systems of various 
modalities. In the presently contemplated embodiment, 
for example, the remote service facility 20 may provide 

35 service to magnetic resonance imaging (MRI) systems, 
computed tomography (CT) systems, positron emission 
tomography (PET) systems, ultrasound systems, x-ray 
systems, and so forth. Moreover, the remote service 
facility may provide similar services to centralized med- 

40 ical diagnostic management systems, picture archiving 
and communications systems (PACS), teleradiology 
systems, and so forth. Such systems will typically be 
either stationary (i:e., located in a known place and 
available by a known network address) or mobile (i.e., 

45 movable and susceptible to positioning at various con- 
figurable network addresses). 

[0014] As illustrated in Fig. 1, certain of the diag- 
nostic equipment may be situated in a single facility or 
institution as shown diagramatically for institution 12. In 

so the illustrated embodiment, three such diagnostic sys- 
tems 22, 24 and 26 are provided in the institution. In a 
typical application, these systems may be similar in 
modality or configuration, or may be of different modali- 
ties and configurations. In a radiology department or 

ss clinic, for example, each of the imaging systems may be 
of a different type to provide various options to the diag- 
nosing physicians and radiologists for imaging various 
anatomies and subjects of interest. Where appropriate, 
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the systems may be networked within the facility, such 
as through a centralized radiology management system 
28. Radiology management system 28 may permit the 
facility to monitor activities, performance, configura- 
tions, and other data from the diagnostic systems. Radi- 
ology management system 28 will include one or more 
operator work stations 30 for interfacing with the man- 
agement data and software. As will be appreciated by 
those skilled in the art, similar operatorinterfaces will 
typically be provided for each diagnostic system 22, 24 
and 26, permitting a radiologist or clinician to request 
and configure various examinations, to review examina- 
tion results, process acquired and stored data files, and 
so forth. Radiology management system 28 is further 
provided with communications components permitting it 
to send and receive data over a communications link as 
indicated generally at reference numeral 32. Similar 
communications links may be provided for each of the 
diagnostic systems within the facility, as indicated at ref- 
erence numeral 34. As described in greater detail 
below, these links permit data to be transferred to and 
from the systems over an open or dedicated network. 
[0015] Various independent diagnostic systems 14 
may be provided in the arrangement 10. In particular, 
independent clinics and departments within hospitals 
and institutions may possess one or more such inde- 
pendent diagnostic systems which may be coupled 
directly to the remote service facility via a communica- 
tions link 36. Similarly, mobile diagnostic systems 16 
and 1 8 may be linked directly to the remote service facil- 
ity via links 38. In general, such mobile diagnostic sys- 
tems may include equipment of various modalities, such 
as MRI or x-ray systems which may be displaced to 
locations to better service patient populations. Finally, 
arrangement 10 may include a series of field engineer 
stations 40 and 42 which may be similarly linked to the 
remote service facility to permit field service engineers 
to exchange data, images, schedules, reports, and the 
like, with the remote service facility. Such field engi- 
neers may be dispatched, for example, to respond to 
particular needs of subscribing systems as these arise. 
[0016] Each of the systems and stations illustrated 
in Fig. 1 may be linked selectively to the remote service 
facility via a network as represented generally at refer- 
ence numeral 44. For the purposes of the present tech- 
nique, any acceptable network may be employed, 
including open and dedicated networks, virtual private 
networks, the Internet, and so forth. Moreover, the com- 
munications links to the network may be of any accept- 
able type, including conventional telephone links, cable 
modem links, digital subscriber lines and the like. Each 
of the systems is provided with communications inter- 
face hardware and software of generally known design, 
permitting them to establish network links with the 
remote service facility, and to exchange data with the 
facility. In the presently preferred configuration, the sys- 
tems are provided with interactive software by which 
messages, image data, service requests, system status 



information, protocols, and so forth may be transmitted 
to and from the system by establishment of the network 
connection. Where desired, during periods when no 
such data is exchanged between the remote service 
5 facility and the subscriDing system, the network connec- 
tion may be terminated. 

[0017] Remote service facility 20, in the diagram- - 
matical view of Fig. 1, includes both communications 
components as well as components for managing provi- 

io sion of service to the medical diagnostic systems. Thus, 
a series of modems 46 are provided for establishing the 
network connection needed for the remote service, and 
for exchanging data over network 44. The modems are 
coupled to communications interface components as 

15 designated generally at reference numeral 48. As will be 
appreciated by those skilled in the art, these compo- 
nents and modems may include hardware and software 
for screening communications between the remote 
service facility and the medical diagnostic systems, 

20 including fire walls. Also, the modems and communica- 
tions interface components may be replaced, where 
appropriate, with alternative communications hardware 
and software, such as cable modems. Communications 
interface components 48 are coupled to a router 50 for 

25 appropriately directing communications to and from the 
medical diagnostic systems coupled to the service facil- 
ity via the network. 

[0018] Service facility 20 is equipped to handle a 
.variety of service requests and functions both at the ini- 

30 tiation of the subscribing diagnostic systems, as well as 
by the service facility itself. In the illustrated embodi- 
ment, a server 52 is illustrated for providing the service 
functionalities described herein. In practice, a variety of 
such servers may be interlinked for various service 

35 functions, including receiving and directing service 
requests, proactively accessing subscribing systems for 
system status data, managing subscribing system 
licenses, and generating reports and messages for 
transmission to the subscribing systems. Certain of the 

40 servers may be protected by firewalls to limit access to 
data. Server 52 may be coupled to one or more data- 
bases 54 for storing information related to the provision 
of services to the various subscribing medical diagnos- 
tic systems. Databases 54 may also store information 

45 relating to performance of the systems, system configu- 
rations, system license and account data, and so forth. 
A series of work stations 56 may be further linked to 
server 52, permitting service facility engineers to 
access data and address service concerns. By way of 

so example, such work stations may be used to trouble 
shoot potential connectivity problems identified by the 
procedure described below. Finally, additional data- 
bases or systems, as represented generally at refer- 
ence numeral 58 in Fig. 1, may be linked to the service 

55 facility to store or archive data for the systems subscrib- 
ing to service from the facility. Certain of the remote 
facilities may be linked in similar ways in various geo- 
graphical locations, such as around a single region or 
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country, or around the world. Databases 58 may further 
include statistical information gathered from a popula- 
tion of diagnostic systems for use in analysis and serv- 
ice to similar systems. 

[001 9] Because the systems of arrangement 1 0 are 
interactively linked to the service facility, it has been 
found desirable to provide a means for verifying that the 
systems can connect to the service facility at will and, 
conversely, that the service facility can readily access 
the subscribing medical diagnostic systems. In general, 
where a system experiences technical difficulties or 
where service requests arise, the inability to contact the 
service facility may result in delay in addressing the 
service concerns. Similarly, even where service con- 
cerns are received from the systems, where the sys- 
tems cannot be recontacted by the service facility, 
alternative and potentially time consuming measures 
must be taken to provide the desired feedback. The 
present technique provides a mechanism for insuring 
connectivity between the medical diagnostic systems 
and the service facility, 

[0020] Fig. 2 illustrates, certain of the functional 
components of the diagnostic systems and of the serv- 
ice facility designed to provide verification of connectiv- 
ity. The components are specifically designed to enable 
connections initiating from either the medical diagnostic 
equipment or from the remote service facility. In a pres- 
ently preferred embodiment, both the subscribing 
equipment and the service facility include network serv- 
ers and server software designed to provide for interac- 
tive exchange of data via the network link. Such servers 
may be based on any known or suitable software or pro- 
tocol, exchanging data, for example, in accordance with 
Point-to-Point Protocol (PPP), employing Internet Proto- 
col (IP) packets, HyperText Transfer Protocol (HTTP), 
and so forth. Moreover, the servers of the systems and 
of the service facility are preferably designed to process 
and transfer data in raw or processed form, such as 
image data processed into a standard DiCOM format. 
Finally, the servers are preferably equipped to support 
HTTP applications, and include a browser capable of 
displaying interactive pages, such as in HTML, XTL, or 
other language configurations, and to support java 
applications, applets, servlets and similar code for car- 
rying out the functions described herein. 
[0021] In the diagrammatical representation of Fig. 
2, the subscribing diagnostic system includes a system 
server 60 which calls upon a connectivity servlet 62 for 
verifying the status of communications components. As 
will be appreciated by those skilled in the art, servlet 62 
may be defined by any appropriate code installed at the 
system or transferred to the system upon demand. As 
described more fully below, in fixed or stationary sys- 
tems, the servlet will be called upon in response to 
receipt of a connectivity verification message from the 
remote service facility, and will thereafter recontact the 
service facility to verify that the two-way connections 
can be readily established. In mobile systems, the con- 



nectivity servlet is adapted to contact the service facility 
upon displacement of the mobile system to a new loca- 
tion, and to receive a verification response to the initi- 
ated contact. 

5 [0022] Within the remote service facility, one or 
more servers 52 are equipped with a series of software 
modules designed to initiate and respond to connectiv- 
ity verification messages, in the diagrammatical repre- 
sentation of Fig. 2, the server includes a connectivity 

10 application 64 which manages the connectivity func- 
tions described below. A scheduler module 66 defines 
timing and contacts initiated by the remote service facil- 
ity for the connectivity verification sequences of sub- 
scribing medical diagnostic systems. A connectivity 

w check-in module 68 serves to receive and exchange 
data with diagnostic systems during the connectivity 
sequences executed by application 64 in accordance 
with the schedules established by module 66. A similar 
mobile check-in module 70 manages exchange of data 

20 with mobile diagnostic systems upon initiation of con- 
nectivity verification sequences with those systems. 
[0023] Server 52 and the coded modules accessed 
by it are further interfaced with blocks of memory for 
storing data used in the connectivity verification proc- 

25 ess. These blocks of memory may be defined in any 
acceptable medium, such as disc drives, magnetic tape, 
optical memory devices, solid state memory, and so 
forth. As illustrated in Fig. 2, memory blocks are pro- 
vided for mobile sites, as indicated at reference numeral 

30 71, storing configuration parameters for subscribing 
mobile sites, as well as system laentmcations, locations, 
access or address numbers and codes, and so forth. A 
license memory block 72 stores data indicative of the 
status of current service licenses for the various sys- 

35 terns, which may include both accounting data, such 
information as date information, expire information, and 
level of service access. A log/event memory block 73 is 
provided to store the results of the connectivity verifica- 
tion sequences executed between the service center 

40 and the various subscribing systems. As indicated 
below, the memory block will generally include historical 
data indicative of the results of connectivity verification 
sequences. The memory block may also include refer- 
ences to specific events, -scheduled service, service 

45 requests, and so forth. An alert log block 74 is provided 
for storing alerts generated by the present technique in 
response to a failure or anomaly in the connectivity ver- 
ification sequence. Such alerts may be used to gener- 
ate dispatches for service engineers both in the field 

50 and at the remote service facility to trouble shoot the 
communications and connection components when 
connectivity problems arise. An alert module 75 serves 
to generate alerts in response to problems with connec- 
tivity, such as electronic messages, pages, service dis- 
ss patches, and the like. An analysis module 76 provides 
analytical capabilities, such as for recognizing patterns 
in connectivity problems for specific systems, or for pop- 
ulations of systems based upon historical records of 
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connections and results of connectivity verification 
sequences. 

[0024] Fig. 3 represents certain of the foregoing 
components and, generally, the types of data exchange 
between the components. As shown in Fig. 3, the con- 
nectivity application 64 provided at the remote service 
facility is designed to exchange data with external cli- 
ents 12 in the form of medical diagnostic systems. It 
should be noted that the connectivity verification proc- 
ess is designed to insure that such data can be interac- 
tively exchanged both from the service facility to the 
diagnostic system, and visa-versa. The client station 
therefor is designed to contact and send data to con- 
nectivity check-in module 68 or 70 (depending upon the 
stationary or mobile nature of the client). In addition to 
the memory blocks represented generally at reference 
numerals 77, 78 and 79, which may correspond gener- 
ally to memories 71 , 72 and 73 described above, con- 
nectivity application 64 is designed to exchange data 
with an interactive software platform 80 which facilitates 
the exchange of service data between the remote serv- 
ice facility and the subscribing systems. In the presently 
preferred embodiment, platform 80 may provide for 
direct or indirect interface between actual modality com- 
ponents, such as MRI or CT scanners, x-ray imaging 
stations, and ultrasound imaging stations. The platform 
may also provide various service functionalities, includ- 
ing electronic messaging, receipt and handling of serv- 
ice requests and questions, image evaluation, imaging 
and processing protocol exchange, system configura- 
tion and data exchange, and so forth. 
[0025] A log module 82 is written into by connectiv- 
ity application 64 to store system log information as indi- 
cated at reference numeral 84. As noted above, such 
log information will typically include records of connec- 
u tivity verification checks, events, service requests, and 
the like. Connectivity application 64 also draws upon 
schedule data as indicated at reference numeral 86 to 
identify which subscribing systems should be contacted 
and at what times of the day or night. As described 
below, because certain systems may be active or inac- 
tive at specific periods, or may be located in various 
time zones, the technique facilitates verification checks 
at various time intervals depending upon system availa- 
bility and responsiveness. Server log data 88 is also 
accessed by connectivity application 64 for review of 
server activities. Data indicative of the most recent veri- 
fication sequence results are stored and accessed as 
indicated at reference numeral 90. A log of open alerts, 
92, may be accessed by connectivity application 64 as 
such alerts are generated, particularly as a result of fail- 
ure or anomalies in the connectivity sequence as 
described below. A log of time slots 94 stores data indic- 
ative of the time periods during which connectivity veri- 
fication sequences have been used successfully and 
unsuccessfully for specific subscribing systems. A log of 
verification or "check-in" times 96 is kept as a record of 
responsiveness of the subscribing systems to connec- 



tivity verification messages from the service facility, as 
well as mobile system-initiated verification sequences. 
A log of previous connections 98 may be accessed by 
application 64, and may serve as a basis for scheduling 

5 verification sequences, as described below. Finally, a 
statistical database 99 is kept with data for systems 
served by application 64, including connectivity statis- 
tics, It should be noted that the logical overview of Fig. 3 
is provided for exemplary purposes only, and modules, 

ro memory designations, logs, and the like for specific sys- 
tems may be tailored in accordance with system needs 
and architecture. 

[0026] As described above, the present system is 
designed to automatically verify status of communica- 
15 tions components for systems subscribing to remote 
service from the service facility. In general, automatic 
connectivity verification sequences may be initiated for 
specific subscriptions, or for all subscribing systems. 
Thus, where the service facility provides for interactive 
20 service arrangements with specific systems, such verifi- 
cation checks may be initiated and carried out on a reg- 
ular or a scheduled basis. At the same time, the service 
facility may provide more limited offerings which do not 
require such connectivity verifications, or require verifi- 
es cations of a limited nature or on a more limited sched- 

[0027] Figs. 4 and 5 illustrate exemplary steps in 
control logic implemented by code at the service facility 
for carrying out the automatic connectivity verification 

30 techniques. Fig. 4 represents exemplary steps for verifi- 
cation of connectivity between the service center and 
systems of known location, typically situated in institu- 
tions, clinics, hospitals, and so forth. The control logic of 
Fig. 4, represented generally by reference numeral 100, 

35 begins at step 1 02 wherein a system is selected for con- 
tact. In the presently contemplated embodiment, the 
system is selected based upon known parameters, 
such as system availability, time slots for the system 
availability, the nature of the system, licensee arrange- 

40 ments for the provision of services to the system, sys- 
tem identification and address, and so forth. In general, 
schedules for connectivity verification may be estab- 
lished in advance and performed automatically. Moreo- 
ver, the schedule may be at least partially based upon 

45 recent historical connections between systems and a 
service facility, with systems having more recently con- 
tacted the service facility being moved to a lower prior- 
ity. Conversely, where historical usage data indicate that 
a system would have been expected to contact the serv- 

50 ice facility within a specified time or at a known fre- 
quency, such systems may be moved up in priority of 
scheduling. Based upon such information, the system is 
contacted at step 104. The contact may be made over 
any suitable network, typically at present over a conven- 

55 tional telephony line via a modem. 

[0028] At step 106, the connectivity application 
determines whether the contact has been successfully 
established. If the contact is not successfully estab- 
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lished, the system may be configured to retry the net- 
work connection as indicated at step 1 08. Moreover, the 
number of attempts to establish the connection, and the 
time between such attempts, may be configured by the 
service facility. Where such subsequent attempts are 
available and desired, the system will attempt such 
recontact by cycling back to step 1 04. If, at step 1 06, the 
contact is successfully established, control advances to 
step 110. 

[0029] If the contact is unsuccessful at step 106, 
various measures may be taken. The inability to estab- 
lish contact may be due to one of a number of factors, 
including the status of the diagnostic system itself, the 
state of transmission lines, communications hardware, 
software, and interface components. Moreover, for cer- 
tain systems, the communications components may be 
occupied or simply unavailable at the period of time in 
which the verification sequence is initiated. If the 
number of attempts permitted at step 1 08 is exhausted, 
an alert is generated as indicated at step 112. The alert 
is stored on an alert log 74 (see Fig. 2) and may be 
accessed by the service facility, such as to generate a 
dispatch for a service engineer or to prompt operator 
intervention in contacting the subscribing system to 
investigate the nature of the connectivity problem. At 
step 114 the failure of the connectivity sequence is 
recorded in a log/event memory 73 (see Fig. 2). 
[0030] Once contact is successfully established at 
step 1 06, data is transmitted between the service facility 
and the subscribing diagnostic system, as indicated at 
step 110. In the presently preferred embodiment, rela- 
tively short messages are transmitted at this step, to 
avoid unnecessarily occupying either the service facility 
or the subscribing system. In general, the data will be 
sufficient to provoke the code at the subscribing system 
to call upon the connectivity servlet and to attempt to re- 
establish contact with the service facility after the con- 
nection is dropped. 

[0031] At step 116, the connectivity application 
determines whether the data has been successfully 
transmitted to the subscribing system. If the data has 
not been successfully transmitted to the system, an 
alert is generated at step 118, signaling to service 
center personnel that an inquiry should be made into 
the nature of the problem prohibiting the transfer of the 
data. The alert is stored in an alert log at the service 
facility. In addition, the failure of the connectivity verifica- 
tion sequence is recorded at step 120. If, on the other 
hand, the data is successfully transmitted at step 116, 
the service facility interrupts the connection as indicated 
at step 122. It should be noted that the present tech- 
nique may be employed for detecting and analyzing the 
status of connectivity over more than one connection 
line. Thus, where desired, the connection established at 
step 104 maybe disconnected as indicated at step 122, 
or may remain connected while the medical diagnostic 
system recontacts the service facility via an alternative 
communications route. 
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[0032] Following the initial contact and transfer of 
data as summarized above, the connectivity application 
awaits a return message from the subscribing system 
contacted. As noted above, the connectivity servlet on 

5 the subscribing system is configured to return the call 
initiated by the service facility to verify that two-way con- 
nectivity is functional. Thus, as indicated at step 124 in 
Fig. 4, the service center awaits the return call during a 
configurable window of time. If the wait period times out 

w prior to receiving the call back from the subscribing sys- 
tem, the foregoing steps in the sequence may be 
repeated as indicated at step 1 26. Again, the number of 
cycles through the connectivity sequence may be set in 
advance. Under normal circumstances, a call is 

; 5 received from the subscribing system and the resulting 
success of the connectivity verification is recorded at 
step 1 28. In the event the sequence is repeated, follow- 
ing the permissible number of attempts to receive the 
return call, an alert is generated as indicated at step 130 

20 and the resulting failure of the connectivity verification 
sequence is recorded at step 132. Such alerts may take 
the form, for example, of electronic messages to service 
personnel, pages to service personnel, service dis- 
patches, and so forth. 

25 [0033] As noted above, certain subscribing systems 
may not be regularly available during certain time slots. 
For example, in a presently preferred configuration, the 
connectivity sequence is attempted in one of three time 
periods distributed through a 24 hour period. If the 

30 results of the sequence summarized in Fig. 4 indicate 
that connection cannot be achieved, at a specific time 
slot, an alternative time slot may be scheduled for the 
system-specific connectivity check sequence. 
[0034] While similar logic may be employed for con- 

35 tacting mobile systems, particularly where the location 
and contact address of such systems are known, in a 
present embodiment, alternative control logic, summa- 
rized in Fig. 5, is employed for such systems, permitting 
the systems to initiate contact with the service facility. 

40 As summarized in Fig. 5, the control logic, designated 
generally by the reference numeral 200, begins at step 
202 wherein the diagnostic system is relocated or posi- 
tioned at a desired location. At step 204, the connectiv- 
ity servlet at the diagnostic system determines whether 

45 a system check-in has been performed within a desired 
amount of time, such as subsequent to the relocation. If 
the check-in has been performed, the logic may be 
exited as indicated at step 206. If no such connectivity 
verification has been performed, or has not been per- 

50 formed within a desired amount of time, or since reloca- 
tion of the system, the server at the diagnostic system 
initiates a network connection with the service center as 
indicated at step 208. 

[0035] Once the connection is established, system 
55 data is transmitted at step 1 1 0, identifying the subscrib- 
ing system, its location, its network address or call 
number, and so forth, It should be noted that, although 
not represented in Fig. 5, intervening logical steps may 
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be included in this routine for signaling that a contact 
could not be established at step 208 or that data could 
not be successfully transmitted at step 210. In either 
event, an alert and failure event may be recorded. Once 
data is successfully transmitted at step 210, the mobile 
diagnostic system interrupts the network connection at 
step 212. 

[0036] In response to the data received from the 
mobile diagnostic system, the service facility recontacts 
the system, as indicated at step 214. The server at the 
mobile diagnostic system may also be configured to 
await a specific amount of time for the verification call 
back as indicated above in the logic of Fig. 4. The serv- 
ice facility determines, at step 21 6, whether the network 
connection could be successfully established with the 
mobile system. If not, the connectivity application at the 
service facility may be configured to reattempt the net- 
work connection as indicated at step 218. If such 
attempts to recontactthe system are unsuccessful, or if 
a desired number of reattempts expires, control 
advances to step 220 where an alert is generated, indi- 
cating that the connectivity verification sequence identi- 
fied a connectivity failure and that additional service 
may be required. At step 222, the results of the connec- 
tivity, verification sequence are recorded. Finally, at step 
224, the system location is recorded for the purposes of 
any further contact which may need to be established 
between the service center and the subscribing mobile 
system. 

[0037] It should be noted that the foregoing logic, 
whether implemented for stationary or mobile systems, 
provides several levels of identification of connectivity 
problems or failures. Specifically, because connectivity 
failures may involve hardware or software difficulties at 
various locations in the network connection, data, trans- 
fer, receipt and processing components, and so forth, it 
has been found useful to provide as much information in 
identifying a connectivity failure as possible. Such indi- 
cations greatly facilitate troubleshooting of the connec- 
tivity components, providing service personnel with a 
clear indication of which portions of the system may be 
functional and which may need review, even without 
requiring direct involvement of personnel at the location 
of the system. For example, in a present configuration, 
a variety of failure modes may be detected based upon 
the point in the logic where the failure took place. Such 
failures may occur, for example, due to the inability of 
the service Tacinty to contact the subscribing system. 
Failures at this point may be attributed to hardware or 
software which is currently occupied at the service facil- 
ity, hardware or software which is currently occupied at 
the subscribing system, failure of the subscribing sys- 
tem to respond to a call, failure of the PPP module at the 
subscribing system to respond, an incorrect IP address, 
and so forth. Moreover, even once the connection is 
established, a failure or anomaly in the data transmis- 
sion may result in identifiable failure modes. Similar fail- 
ures may occur from an inability of the subscribing 
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system to recontact the service facility. Moreover, fail- 
ures may occur due to an inability to access an HTTP 
server or the connectivity servlet. Other events may be 
similarly recorded, such as the failure of the subscribing 
5 system to call back or to call back within a desired time 
window. 

[0038] It should also be noted that the foregoing 
technique may be employed to verify connectivity with a 
large number of systems in an automated manner. The 

w connectivity verification and response sequences may 
be carried out at any convenient time, such as during 
off-peak hours. The scheduled order of performing the 
verification checks may also be influenced by recent 
activities (e.g. data exchanges) between specific sys- 

is terns and the service facility. For example, where a sys- 
tem would be scheduled for connectivity verification but 
recently contacted the service facility, that system may 
be rescheduled for a later time, freeing the schedule for 
systems which have not successfully contacted the 

20 service facility within a desired time frame. Similarly, 
based upon historical data for a system, the service 
facility may move the system up on a connectivity verifi- 
cation schedule, considering that the inactivity may be 
indicative of a problem in the system connectivity hard- 

25 ware or software. Both for individual systems, and for 
entire populations of systems, the results of the connec- 
tivity verification sequences may be used for analysis of 
system and component performance, and for system 
design or improvement. 

30 [0039] The present technique has been set forth 
and described herein by way of example only. The 
invention is not intended to be limited to this or any par- 
ticular embodiment, but is intended to extend to the full 
legally permissible scope of the appended claims. Vari- 

35 ous alternative arrangements and configurations may 
1 be envisaged by those skilled in the art which neverthe- 
less fall within the scope of the claims. For example, the 
particular configuration of the diagnostic systems, or of 
the service facility may be adapted to accommodate 

40 specific types of hardware, software, and so forth. Simi- 
larly, the logical steps described above for establishing 
and verifying the interactive network connection 
between subscribing systems and the service facility 
may be subject to a wide variety of modifications, partic- 

45 ularly in the details related to the establishment, 
processing, and verification of the network connections, 
and in evaluations of the various failure modes. 
[0040] For completeness, various aspects of the 
invention are set out in the following numbered 

so clauses:- 

1. A method for verifying connectivity of a medical 
diagnostic service system, the system including at 
least one medical diagnostic station and a service 
55 facility remote from the diagnostic station, the 
method comprising the steps of: 

(a)performing a connectivity check sequence in 
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which a network connection i 
between the diagnostic station and the service 
facility and, if the connection is established, 
data is transmitted from service facility to the 
diagnostic station; 

(b) performing a connectivity response 
sequence in which a second network connec- 
tion is attempted between the diagnostic sta- 
tion and the service facility in response to the 
connectivity check and, if the connection is 
established, data is transmitted from the diag- 
nostic station to the service facility; and 

(c) recording results of steps (a) and (b). 

2. The method of clause 1 , wherein step (a) is per- 
formed automatically on a scheduled basis. 

3. The method of clause 1 , wherein the connectivity 
check sequence of step (a) is initiated by the serv- 
ice facility. 

4. The method of clause 1 , wherein data necessary 
for attempting the connection in step is stored in a 
database accessed by the service facility. 

5. The method of clause 4, wherein the database 
includes connection data for a plurality of subscrib- 



6. The method of clause 1, wherein the diagnostic 
station includes medical diagnostic equipment con- 
figured to generated image data of a subject of 



7. The method of clause 6, wherein the diagnostic 35 
station includes a plurality of medical imaging sys- 
tems of at least one modality. 

8. The method of clause 1, including the further 
step of generating an alert message if the attempt 40 
at step (a) or (b) is unsuccessful in establishing the 
respective network connection. 

9. The method of clause 1, including the further 
step of repeating either step (a) or step (b) if the . 45 
attempt to establish the respective network connec- 
tion is unsuccessful. 

1 0. The method of clause 1 , wherein the diagnostic 
station is a mobile diagnostic station. so 

11. The method of clause 1, wherein step (a) is 
repeated during at least two different time slots to 
determine connectivity at corresponding times. 

12. A method for verifying connectivity between a 
plurality of medical diagnostic stations and a 
remote service facility, the method comprising the 



(a) scheduling connectivity checks for each of a 
plurality of subscribing diagnostic stations; 

(b) initiating respective network connections 
between the service facility and the diagnostic 
stations in accordance with a schedule estab- 
lished in step (a) and, if the respective connec- 
tion is established, transferring data to the 
service station; 

(c) initiating respective second network connec- 
tions between the service facility and the diag- 
nostic stations in response to the data 
transferred in step (b); and 

(d) recording results of steps (b) and (c). 

13. The method of clause 12, wherein the connec- 
tivity checks are scheduled within one of a plurality 
of different time slots. 

14. The method of clause 1 2, wherein the time slots 
during which each connectivity check is scheduled 
is based upon past successful connectivity checks. 

15. The method of clause 12, wherein a plurality of 
connectivity check sequences are scheduled such 
that an anticipated time for second network connec- 
tion for a first diagnostic station overlaps with an 
anticipated time for a second network connection 
with a second diagnostic station. 

16. The method of clause 12, wherein the connec- 
tivity checks are scheduled based upon subscrip- 
tion status for each of the plurality of diagnostic 
stations. 

1 7. The method of clause 1 2, comprising the further 
step of generating an alert message if respective 
network connection initiated at steps (b) or (c) is 
unsuccessful for a diagnostic station. 

18. The method of clause 12, including the further 
step of analyzing results of steps (b) and (c) to 
determine a probable failure point in the network 
connection. 

19. The method of clause 1 8, including the step of 
recording the failure point with the results of steps 
(a) and (b) for a 



20. A method for verifying connectivity between a 
medical diagnostic system service facility and a 
mobile diagnostic system, the "method comprising 



(a)performing a connectivity check sequence 
from the mobile diagnostic station to the serv- 
ice facility during which a network connection is 
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initiated and, if a network connection is suc- 
cessfully established, data is transferred to the 
service facility; 

(b) performing a connectivity response 
sequence in response to the connectivity check 
sequence, during which a network connection 
is initiated by the service facility and, if the net- 
work connection is successfully established, 
data is transferred to the mobile diagnostic sta- 
tion; and 

(c) recording results of steps (a) and (b). 

20. The method of clause 19, wherein data trans- 
ferred from the mobile diagnostic system in step (a) 
includes data indicative of a location of the mobile 



21. The method of clause 19, wherein the mobile 
diagnostic system is configured to perform step (a) 
following displacement of the mobile diagnostic 20 
system from a first location to a second location. 

22. The method of clause 19, including the further 
step of generating an alert record if a network con- 
nection cannot be established at either step (a) or 25 
(b). 

23. The method of clause 19, including the further 
step of generating an alert record if data cannot be 
accurately transferred in either step (a) or (b). 30 

24. A method for analyzing connectivity of a medi- 
cal diagnostic service system, the system including 
at least one medical diagnostic station and a serv- 
ice facility remote from the diagnostic station, the 35 
method comprising the steps of: 

(a)performing a connectivity check sequence in 
which a network connection i 
between the diagnostic station and the si 
facility and, if the connection ii 
data is transmitted from service facility to the 



(b) performing a connectivity response 
sequence in which a second network connec- 
tion is attempted between the diagnostic sta- 
tion and the service facility in response to the 
connectivity check and, if the connection is 
established, data is transmitted from the diag- 
nostic station to the service facility; 

(c) recording results of steps (a) and (b); and 

(d) analyzing the results stored in step (c) to 
determine a point of possible connectivity fail- 
ure between the diagnostic station and the 
service facility. 

25. The method of clause 24, wherein the analysis 
performed in step (d) includes accessing historical 



records for the diagnostic system from a data stor- 
age location. 

26. The method of clause 24, wherein the analysis 
performed in step (d) includes identifying a point in 
step (a) at which the connectivity check sequence 



27. The method of clause 24, wherein the analysis 
performed in step (d) includes identifying a point in 
step (b) at which the connectivity response 
sequence failed. 

28. The method of clause 24, wherein the connec- 
tivity check sequence and the connectivity 
response sequence are performed on a plurality of 
diagnostic stations in accordance with a predeter- 
mined schedule. 

29. The method of clause 28, wherein an order of 
priority for each diagnostic station on the schedule 
is at least partially based upon historical records of 
network connections initiated by the respective 
diagnostic stations with the service facility. 

30. A system for providing remote service to a med- 
ical diagnostic system, the system comprising: 

a medical diagnostic system configured to 
process medical image data; 
a service facility remote from the diagnostic 
system and configured to provide remote serv- 
ice to the diagnostic system via a network link; 
first connectivity verification means at the serv- 
ice facility, the first connectivity verification 
means configured to attempt to establish a net- 
work connection with the diagnostic system in 
accordance with a connectivity verification rou- 
tine, and to transmit data to the diagnostic sys- 
tem if the network connection is successfully 
established; and 

second connectivity verification means at the 
diagnostic system, the second connectivity ver- 
ification means configured to attempt to estab- 
lish a network connection with the service 
facility in response to the data transmitted dur- 
ing the connectivity verification sequence. 

31. The system of clause 30, wherein the medical 
diagnostic system includes an imaging station of a 
modality selected from a group including MRI sys- 
tems, x-ray systems, CT systems and ultrasound 
systems. 

32. The system of clause 30, wherein the medical 
diagnostic system includes a management station 
coupled to at least one medical diagnostic imaging 
system. 
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33. The system of clause 30, wherein the first con- 
nectivity verification means is configured to execute 
the connectivity verification routine automatically 
based upon a predetermined schedule. 

34. The system of clause 30, wherein the first con- 
nectivity verification means is configured to gener- 
ate and store an alert message if the connectivity 
verification routine determines that two-way net- 
work communication with the medical diagnostic 
system cannot be successfully established. 

35. A system for providing remote service to a med- 
ical diagnostic system, the system comprising: 

a medical diagnostic system configured to 
process medical image data; 
a service facility remote from the diagnostic 
system and configured to provide remote serv- 
ice to the diagnostic system via a network link; 
first connectivity verification means at the med- 
ical diagnostic system, the first connectivity 
verification means configured to attempt to 
establish a network connection with the service 
facility in accordance with a connectivity verifi- 
cation routine, and to transmit data to the serv- 
ice facility if the network connection is 
successfully established; and 
second connectivity verification means at the 
service facility, the second connectivity verifica- 
tion means configured to attempt to establish a 
network connection with the diagnostic system 
in response to the data transmitted during the 
connectivity verification sequence. 

36. The system of clause 35, wherein the medical 
diagnostic system is a mobile system displaceable 
between desired locations remote from the service 
facility. 

37. The system of clause 35, wherein the first or the 
second connectivity verification means is config- 
ured to generate and store an alert message if a 
network connection cannot be successfully estab- 
lished or if data cannot be successfully transferred 
between the diagnostic system and the service 
facility during the connectivity verification routine. 



A method for verifying connectivity of a medical 
diagnostic service system,, the system including at 
least one medical diagnostic station (12, 14, 16, 18, 
22, 24, 26) and a service facility (20) remote from 
the diagnostic station, the method comprising the 
steps of: 

(a) performing a connectivity check sequence 



in which a network connection (32, 3' 
is attempted (1 04) between tr 
tion and the service facility and, if the connec- 
tion is established, data is transmitted (110) 
from service facility to the diagnostic station; 

(b) performing a connectivity response 
sequence in which a second network connec- 
tion (32, 34, 36, 38) is attempted (1 24) between 
the diagnostic station and the service facility in 
response to the connectivity check and, if the 
connection is established, data is transmitted 
from the diagnostic station to the service facil- 
ity; and 

(c) recording results (114, 120, 128) of steps 
(a) and (b). 

2. The method of claim 1, wherein step (a) is per- 
formed automatically on a scheduled basis. 

3. The method of claim 1, wherein the connectivity 
check sequence of step (a) is initiated by the serv- 
ice facility (20). 

4. The method of claim 1 , wherein data necessary for 
attempting the connection in step (a) is stored in a 
database (54, 58) accessed by the service facility 
(20). 

5. The method of claim 1 , including the further step of 
generating an alert message (112, 118, 130) if the 
attempt at step (a) or (b) is unsuccessful in estab- 
lishing the respective network connection. 

6. The method of claim 1 , including the further step of 
repeating (108, 126) either step (a) or step (b) if the 
attempt to establish the respective network connec- 
tion is unsuccessful. 

7. A system for providing remote service to a medical 
diagnostic system, the system comprising: 

a medical diagnostic system (12, 14, 16, 18, 
22, 24 26) configured to process medical 
image data; 

a service facility (20) remote from the diagnos- 
tic system and configured to provide remote 
service to the diagnostic system via a network 
link (44); 

first connectivity verification means (64, 66, 68, 
70) at the service facility, the first connectivity 
verification means configured to attempt to 
establish a network connection with the diag- 
nostic system in accordance with a connectivity 
verification routine (100, 200), and to transmit 
data to the diagnostic system if the network 
connection is successfully established; and 
second connectivity verification means (60, 62) 
at the diagnostic system, the second connec- 



11 



21 EP 1 081 627 A2 

tivity verification means configured to attempt 
to establish a network connection with the 
service facility (20) in response to the data 
transmitted during the connectivity verification 
sequence (100, 200). s 

8. The system of claim 7 wherein the medical diag- 
nostic system includes a management station (28) 
coupled to at least one medical diagnostic imaging 
system (22, 24, 26). w 

9. The system of claim 7, wherein the first connectivity 
verification means (64, 66, 68, 70) is configured to 
execute the connectivity verification routine (100, 
200) automatically based upon a predetermined 15 
schedule. 

10. The system of claim 7, wherein the first connectivity 
verification means (64, 66, 68, 70) is configured to 
generate and store an alert message (112, 118, 20 
130) if the connectivity verification routine deter- 
mines that two-way network communication with 

the medical diagnostic system cannot be success- 
ful ly.es 
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FIG. 4 

100 



SERVICE CENTER 
SYSTEM TO 
CONTACT 



I 

104 1 CONTACT SYSTEM [ < 




110 





YES 


TRANSMIT CHECK 
DATA 









16 



EP 1 081 627 A2 



202 



' 1 RELOCATE MOBILE SYSTEM 



200 
\ 



208-^ 
210 

212 - 
214 — 




> CONTACT SERVICE 
CENTER 






TRANSMIT 

DAI 


SYSTEM 
fA 



DISCONNECT 

~1~ 



SERVICE CENTER 
RECONTACT SYSTEM 




^CONTACT \ N0 
SUCCESSFUL . 



222 * 



RECORD 
RESULTS 



"RETRr 



218 



GENERATE 
ALERT 



RECORD SYSTEM 
LOCATION 



17 



